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Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2005). 
Abstract 


This document describes how to carry 64 kbit/s channel data 
transparently in RTP packets, using a pseudo-codec called 
"Clearmode". It also serves as registration for a related MIME type 
called "audio/clearmode". 


"Clearmode" is a basic feature of VoIP Media Gateways. 
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1. Introduction 


Voice over IP (VoIP) Media Gateways need to carry all possible data 
streams generated by analog terminals or integrated services digital 
network (ISDN) terminals via an IP network. Within this document a 


VoIP Media Gateway is a device that converts a (digital or analog) 
linear data stream to a digital packetized data stream or vice versa. 
Refer to RFC 2719 [10] for an introduction into the basic 
architecture of a Media Gateway based network. 


Usually a VoIP Media Gateway does some processing on the data it 
converts besides packetization or depacketization; i.e. echo 
cancellation or dual tone multifrequency (DTMF) detection, and 
especially a coding/decoding. But there is a class of data streams 
that does not rely on or allow any data processing within the VoIP 
Media Gateway except for packetization or depacketization. ISDN data 
terminals i.e. will produce data streams that are not compatible with 
a non-linear encoding as used for voice. 


For such applications, there is a necessity for a transparent relay 


of 64 kbit/s data streams in real-time transport protocol (RTP) [4] 
packets. This mode is often referred to as "clear-channel data" or 
"64 kbit/s unrestricted". No encoder/decoder is needed in that case, 


but a unique RTP payload type is necessary and a related MIME type is 
to be registered for signaling purposes. 


Clearmode is not restricted to the examples described above. It can 
be used by any application, that does not need a special 
encoding/decoding for transfer via a RTP connection. 


This payload format document describes a pseudo-codec called 
"Clearmode", for sample oriented 64 kbit/s data streams with 8 bits 
per sample. It is in accordance with RFC 2736 [1], which provides a 
guideline for the specification of new RTP payload formats. 


Examples for the current use of Clearmode are the transfer of "ISDN 7 
kHz voice" and "ISDN data" in VoIP Media Gateways. 


This document also serves as the MIME type registration according to 
RFC 2045 [2] and RFC 2048 [3], which defines procedures for 
registration of new MIME types within the IETF tree. 


2. Conventions Used in This Document 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 


"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [8]. 
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64 kbit/s Data Stream Handling and RTP Header Parameters 


Clearmode does not use any encoding or decoding. It just provides 
packetization. 


Clearmode assumes that the data to be handled is sample oriented with 
one octet (8bits) per sample. There is no restriction on the number 
of samples per packet other than the 64 kbyte limit imposed by the IP 
protocol. The number of samples SHOULD be less than the path maximum 
transmission unit (MTU) minus combined packet header length. If the 
environment is expected to have tunnels or security encapsulation as 
part of operation, the number of samples SHOULD be reduced to allow 
for the extra header space. 


The payload packetization/depacketization for Clearmode is similar to 
the Pulse Code Modulation (PCMU or PCMA) handling described in RFC 
3551 [5]. Each Clearmode octet SHALL be octet-aligned in an RTP 
packet. The sign bit of each octet SHALL correspond to the most 
significant bit of the octet in the RTP packet. 


A sample rate of 8000 Hz MUST be used. 
This calculates to a 64 kbit/s transmission rate per channel. 


The Timestamp SHALL be set as described in RFC 3550 [4]. 


The marker bit is always zero. Silence suppression is not applicable 
for Clearmode data streams. 


The payload type is dynamically assigned and is not presented in this 
document. 


RTP header fields not mentioned here SHALL be used as specified in 
RFC 3550 [4] and any applicable profile. 


This document specifies the use of RTP over unicast and multicast UDP 
as well as TCP. (This does not preclude the use of this definition 
when RTP is carried by other lower-layer protocols.) 


IANA Considerations 
This document registers the following MIME subtype: audio/clearmode. 
To: ietf-types@iana.org 
Subject: Registration of MIME media type audio/clearmode 


MIME media type name: audio 
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MIME subtype name: clearmode 

Required parameters: none 

Optional parameters: ptime, maxptime 
"ptime" gives the length of time in milliseconds 
represented by the media in a packet, as described in RFC 
2327 [6]. 
"maxptime" represents the maximum amount of media, which 
can be encapsulated in each packet, expressed as time in 
milliseconds, as described in RFC 3267 [9]. 

Encoding considerations: 
This type is only defined for transfer via RTP [4]. 

Security considerations: 
See Section 6 of RFC 4040 

Interoperability considerations: none 

Published specification: RFC 4040 

Applications, which use this media type: 
Voice over IP Media Gateways, transferring "ISDN 64 kb/s 
data", "ISDN 7 kHz voice", or other 64 kbit/s data streams 
via an RTP connection 
Note: the choice of the "audio" top-level MIME type was 
made because the dominant uses of this pseudo-codec are 
expected to telephony and voice-gateway-related. The 
"audio" type allows the use of sharing of the port in the 
SDP "m=" line with codecs such as audio/g711 [6], [7], for 
one example. This sharing is an important application and 
would not be possible otherwise. 

Additional information: none 

Intended usage: COMMON 


Author/Change controller: 


IETF Audio/Video transport working group 
delegated from the IESG 
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5. Mapping to Session Description Protocol (SDP) Parameters 
Parameters are mapped to SDP [6] in a standard way. 
o The MIME type (audio) goes in SDP "m=" as the media name. 


o The MIME subtype (clearmode) goes in SDP "a=rtpmap" as the 
encoding name. 


O The optional parameters "ptime" and "maxptime" go in the SDP 
"a=ptime" and "a=maxptime" attributes, respectively. 


An example mapping is as follows: 
audio/clearmode; ptime=10 
m=audio 12345 RTP/AVP 97 
a=rtpmap:97 CLEARMODE/ 8000 


a=ptime:10 


Note that the payload format (encoding) names defined in the RTP 
Profile are commonly shown in upper case. MIME subtypes are commonly 


shown in lower case. These names are case-insensitive in both 
places. 
6. Security Considerations 


Implementations using the payload format defined in this 
specification are subject to the security considerations discussed in 
the RFC 3550 [4]. The payload format described in this document does 
not specify any different security services. The primary function of 
this payload format is to add a transparent transport for a 64 kbit/s 
data stream. 


Confidentiality of the media streams is achieved by encryption, for 
example by application of the Secure RTP profile [11]. 


As with any IP-based protocol, in some circumstances a receiver may 
be overloaded simply by the receipt of too many packets, either 
desired or undesired. Network-layer authentication MAY be used to 
discard packets from undesired sources, but the processing cost of 
the authentication itself may be too high. Overload can also occur, 
if the sender chooses to use a smaller packetization period, than the 
receiver can process. The ptime parameter can be used to negotiate 
an appropriate packetization during session setup. 
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7. 


In general RTP is not an appropriate transfer protocol for reliable 
octet streams. TCP is better in those cases. Besides that, packet 
loss due to congestion is as much an issue for clearmode, as for 
other payload formats. Refer to RFC 3551 [5], section 2, fora 
discussion of this issue. 
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